Method and system for unique, procedurally generated digital objects via few-shot model

ABSTRACT

Disclosed herein is digital object generator that makes uses a one-way function to generate unique digital objects based on the user specific input. Features of the input are first extracted via a few-shot convolutional neural network model, then evaluated weight and integrated fit. The resulting digital object includes a user decipherable output such as a visual representation, an audio representation, or a multimedia representation that includes recognizable elements from the user specific input.

TECHNICAL FIELD

The disclosure relates to digital input handling and processing togenerate digital composite objects. The disclosure more specificallyrelates to unique, procedurally generated digital objects using one-wayfunctions.

BACKGROUND

A computer can use random elements to generate unique, or seeminglyunique, procedurally generated digital objects (e.g., graphics).However, human viewers typically do not appreciate something as uniqueif it is merely random. Thus, procedural generation of digital objectsis lacking in programming to interpret when output is merely random orwhen it has displayed machine creativity. Prior art has attempted toaddress the randomness issue by providing a set of preset componentsthat are easily intermingled. However, this solution is limited tocombinations of presets and thus repeats, or near-repeat digital objectsas output are likely.

Tangentially, a one-way function is a function that is easy to computeon every input, but hard to invert given the image of a random input.Here, “easy” and “hard” are to be understood in the sense ofcomputational complexity theory, specifically the theory of polynomialtime problems.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of a sample few-shot model configured toderive graphic features.

FIG. 2 is a block diagram illustrating a data structure of a smartcontract.

FIG. 3 illustrates a block diagram of a system for using emoji sequenceIDs for identifying wallet addresses of blockchain wallets.

FIG. 4 is a flowchart illustrating platform generation of a uniqueprocedurally generated object via user specific parameters.

FIG. 5 is an illustration of a new digital object generated from a setof user input.

FIG. 6 is a flowchart illustrating model operation step of a uniqueprocedurally generated object via user specific parameters.

FIG. 7 is a flowchart illustrating implementation of time-based input todigital object generation.

FIG. 8 is a diagram illustrating a connection between digital objectsand a distributed consensus network supported by a blockchain datastructure.

FIG. 9 is a flowchart illustrating event driven generation of digitalobjects.

FIG. 10 illustrates a number of emoji sequences that are connected viasocial networking features based on the features included in each emojisequence.

FIG. 11 is a block diagram of an exemplary computing system.

FIG. 12 is a block diagram illustrating an example machine learning (ML)system, in accordance with one or more embodiments

DETAILED DESCRIPTION

Disclosed herein is a generator of unique, procedurally generateddigital objects that makes use of user specific parameters. Computerscan generate unique digital output quite easily through the userandomizing elements. This type of output results in something that isstrictly unique or seemingly unique, but a human viewer is notnecessarily going to appreciate the output as unique. Depending on thestyle of the output, the uniqueness manifests in different ways. Forpurposes of ease of disclosure, this application largely focuses ongraphical elements, but textual, audio, or multimedia elements aresimilarly implementable.

Prior art techniques have made use of preset elements that are reused ina random order. This sort of process is ultimately subject to the sizeof the presets used, but nevertheless, often appears to output similardigital objects over time. A way to overcome the similarity betweenoutput is to unbound the input such that each user is able to submittheir own input, based on user specific parameters. While the algorithmfor generating the procedural digital object does not change, the variedinput enables more unique objects to be created. Further, the digitalobjects created are more personalized to those who instigate thegeneration.

With respect to user submitted input on “unique” output, a platformneeds a scheme to address the potential of double submission of the sameinput. In some embodiments, input is validated such that an exact set ofinput may only be submitted once. In some embodiments, a user isvalidated such that that user may only submit input once (and in amanner, the user themselves acts as the variation in input). In someembodiments, a randomization element is applied to each submission. Therandomization element (e.g., a salt) is implementable in a number ofways. In some embodiments, the salt changes the manner of proceduralgeneration based on the input. In some embodiments, the salt is treatedin the same manner as the input and acts an additional element of input.

A specific example of an embodiment of the present invention relates tothe generation of cryptographic tokens, or more specificallynon-fungible cryptographic tokens (NFT). In some embodiments, theprocedurally generated digital object is generated based on existingelements in a cryptographic wallet. A given cryptographic wallet has anumber of NFTs present therein. The generator of digital objectsinterprets the various cryptographic protocols related to the NFTspresent in the wallet, identifies content associated therewith, andprocedurally generates a new NFT based on the existing ones present inthe wallet.

Examples of uses of digital objects include as collectors items, ticketsfor events, identity information, art, and/or social networking orcommunity building tokens.

Artificial Intelligence and Few-Shot Models

Artificial intelligence models often operate based on extensive andenormous training models. The models include a multiplicity of inputsand how each should be handled. Then, when the model receives a newinput, the model produces an output based on patterns determined fromthe data it was trained on. Few-shot models use a small number of inputs(a support set) to identify some information about a query input.

The term “few-shot” refers to a model that is trained to interpret a fewsources of input data that the model has not necessarily observedbefore. Few-shot is shorthand for stating that the model has “a fewshots” to determine what the user is seeking. “A few” does notnecessarily refer to “three” as is often applied, but a relatively smallnumber when compared to other models known in the art. Few-shot learning(FSL) refers to the training of ML algorithms using a very small set oftraining data (e.g., a handful of images), as opposed to the very largeset that is more often used. This commonly applies to the field ofcomputer vision, where it is desirable to have an object categorizationmodel work well without thousands of training examples.

FSL is utilized in the field of computer vision, where employing anobject categorization model still gives appropriate results even withouthaving several training samples. For example, where a system categorizesbird species from photos, some rare species of birds may lack enoughlabeled pictures to be used as training images. Consequently, if thereis a classifier for bird images, with the insufficient amount of thedataset, a solution would employ FSL.

In some embodiments, a few-shot model uses 10 or fewer input examples,20 or fewer, 100 or fewer input examples, or 5-7 input examples. Whenapplied to graphic element/feature identification, the number of inputexamples may be directly correlated with the number of graphic featuresthat are possible in queries. The referenced input examples differ fromthose the model is trained with in that those examples used during thefew-shot do not necessarily have any relationship (with the exception ofhaving a comparable data type, like the use of ASCII characters, orimage data). The training of the model is premised in teaching the modelhow to quickly adapt to new training examples, rather than to recognizea given input strictly based on examples that it has seen duringtraining. Rather than evaluate individual inputs, the few-shot model istrained to evaluate few-shots-specifically relationships that existbetween the various examples within the few-shot.

Previous work on FSL requires that each example in the support set(examples for the model to adapt quickly to) contain only a singlelabel. For example, suppose a model can quickly learn to classify imagesof a rare bird species. Prior work requires that each image in thesupport set contain a single bird. Other work relating to few-shotmodels and relation network models include the following references:

-   Yutian Chen, Yannis M. Assael, Brendan Shillingford, David Budden,    Scott E. Reed, Heiga Zen, Quan Wang, Luis C. Cobo, Andrew Trask, Ben    Laurie, Çaglar Gülçehre, Aaron van den Oord, Oriol Vinyals, and    Nando de Freitas. Sample Efficient Adaptive Text-to-Speech. CoRR,    abs/1809.10460, 2018.-   Chelsea Finn, Pieter Abbeel, and Sergey Levine. Model-Agnostic    Metalearning for Fast Adaptation of Deep Networks. CoRR,    abs/1703.03400, 2017.-   Gregory R. Koch. Siamese Neural Networks for One-Shot Image    Recognition. 2015.-   Scott E. Reed, Yutian Chen, Thomas Paine, Aaron van den Oord, S. M.    Ali Eslami, Danilo Jimenez Rezende, Oriol Vinyals, and Nando de    Freitas. Few-shotAutoregressive Density Estimation: Towards Learning    to Learn Distributions. CoRR, abs/1710.10304, 2017.-   Florian Schroff, Dmitry Kalenichenko, and James Philbin. Facenet: A    Unified Embedding for Face Recognition and Clustering. CoRR,    abs/1503.03832, 2015.-   Flood Sung, Yongxin Yang, Li Zhang, Tao Xiang, Philip H. S. Torr,    and Timothy M. Hospedales. Learning to Compare: Relation Network for    Few-shot Learning. CoRR, abs/1711.06025, 2017.-   Oriol Vinyals, Charles Blundell, Timothy P. Lillicrap, Koray    Kavukcuoglu, and Daan Wierstra. Matching Networks for One Shot    Learning. CoRR, abs/1606.04080, 2016.

Few-shot models typically make use of convolutional neural networkspre-trained for feature extraction. Pretraining includes a large amountof media training data. Output of the pretraining model is a set ofvectors. Training for such a network may implement supervised learningor with a Siamese network. Different manners of training will affectoutput prediction accuracy. The output vectors are normalized in orderto establish a common output type for purposes of comparison.

FIG. 1 is an illustration of a sample few-shot model 100 configured toderive graphic features. The sample illustrated is a simplisticimplementation utilizing relatively few, and easy to recognize graphicfeatures. This disclosure is not limited to such simple implementationsand the relevant models may be configured to operate and identify morecomplex sets of graphic features.

In the example, model 100, is a few-shot model designed to identify andcategorize graphic features that are received. In some embodiments, themodel 100 is configured with a set list of graphic features to observe(indicated by a graphic feature matrix). In other embodiments, Model 20includes no explanation what a support set includes and instead merelyidentifies similar patterns in pixels.

The illustration of FIG. 1 includes a three-image support set 102, 104,106 and a single query image 108. The images include some combination ofthree graphical features depicting a frog, a cat, or a dog. When eachimage 102, 104, 106, 108 is supplied to the model 100, the model 100generates a respective vector that describes the image content. Eachvector 110, 112, 114, 116 includes a set of dimensions that together areindicative of the graphic content of the images 102, 104, 106, 108.Image A 102 corresponds to vector A 110. Image B 104 corresponds tovector B 112. Image C 106 corresponds to vector C 114. The query image108 corresponds to the query vector 116. In some embodiments, thesupport set vectors 110, 112, 114 and the query vector 116 are apredetermined number of dimensions in length. Dimensions may relatedirectly to graphical features on a one-to-one basis, or multipledimensions may be used to describe a given graphic feature.

As depicted in the figure, the query image 108 does not include acombination of graphic features that exist in any of the support set.Each feature exists in the support set, but not necessarily by itself,or with an exact same combination. While a human observer can readilyidentify the content of the query image, the image identification systemis taught how to identify via few-shot models.

References to “a model” as discussed herein may refer to a heuristicmodel, an artificial intelligence model, a neural network, aconvolutional neural network, a hidden Markov model, an FSL model, oranother suitable ML model known in the art.

Cryptographic Platforms

Public and private keys are an integral component of cryptocurrenciesbuilt on blockchain networks and are part of a larger field ofcryptography known as public-key cryptography (PKC) or asymmetricencryption. The goal of PKC is to easily transition from a first state(e.g., a private key) to a second state (e.g., a public key) whilereversing the transition from the second state to the first state nearlyimpossible, and in the process, proving possession of a secret keywithout exposing that secret key. The product is subsequently a one-waymathematical function, which makes it ideal for validating theauthenticity of transactions such as cryptocurrency transactions becausepossession of the first state such as the secret key cannot be forged.PKC relies on a two-key model, the public and private key.

The general purpose of PKC is to enable secure, private communicationusing digital signatures in a public channel that is susceptible topotentially malicious eavesdroppers. In the context of cryptographictokens, the goal is to prove that a traded token was indeed signed bythe owner of that token, and was not forged, all occurring over a publicblockchain network between peers. A private key of a blockchain walletunlocks the right for the blockchain wallet's owner to spend transfertokens in the blockchain wallet and therefore must remain private. Awallet address of the blockchain wallet is cryptographically linked tothe blockchain wallet's private key and is publicly available to allusers to enable other users to send NFTs to the user's blockchainwallet. For example, the wallet address may be a public key generatedfrom the blockchain wallet's private key using one or more PKCalgorithms. Public keys are generally used to identify wallets, whereasthe private keys are used to authorize actions of the respective wallet.

Wallet addresses for blockchain wallets are typically represented inhuman-legible form in one of three ways: as a hexadecimalrepresentation, as a Base64 representation, or as a Base58representation. In each of these common ways of representing the walletaddresses, each wallet address is represented using a string of lettersand numbers, typically exceeding 20 characters in length. The length andrandomness of the alphanumeric string makes the wallet address unwieldyand difficult to remember, thereby decreasing its usability andhindering the adoption of cryptocurrencies.

Structurally, in some embodiments, customized, flexible cryptographictokens connected to a smart contract are powered by a less flexible,base cryptocurrency. Miners operating on the network for the basecryptocurrency power execution of a distributed application (dApp) orsmart contract. The smart contract is held by an administrative user andincludes all of the custom cryptographic tokens. The customcryptographic tokens do not “move” in the same sense that the basecryptocurrency moves via transactions. The smart contract is “held” bythe administrative user though secondary users may interact with thesmart contract and various portions (specific tokens) may be attributedto those secondary users.

FIG. 2 is a block diagram illustrating a data structure of a smartcontract. Smart contracts and dApps execute on an Ethereum virtualmachine (“EVM”). The EVM is instantiated on available network nodes.Smart contracts and dApps are applications that execute; thus, theprocessing power to do so must come from hardware somewhere. Nodes mustvolunteer their processors to execute these operations based on thepremise of being paid for the work in Ethereum coins, referred to asEther, measured in “gas.” Gas is the name for a unit of work in the EVM.The price of gas can vary, often because the price of Ether varies, andis specified within the smart contract/dApp.

Every operation that can be performed by a transaction or contract onthe Ethereum platform costs a certain number of gas, with operationsthat require more computational resources costing more gas thanoperations that require few computational resources. For example, at thetime of writing, a multiplication instruction requires 5 gas, whereas anaddition instruction requires 3 gas. Conversely, more complexinstructions, such as a Keccak256 cryptographic hash requires 30 initialgas and 6 additional gas for every 256 bits of data hashed.

The purpose of gas is pay for the processing power of the network onexecution of smart contracts at a reasonably steady rate. That there isa cost at all ensures that the work/processing being performed is usefuland valuable to someone. Thus, the Ethereum strategy differs from aBitcoin transaction fee, which is only dependent on the size inkilobytes of a transaction. As a result that Ethereum's gas costs arerooted in computations, even a short segment of code can result in asignificant amount of processing performed. The use of gas furtherenforces incentivizes coders to generate efficient smartcontracts/algorithms. Otherwise, the cost of execution may spiral out ofcontrol. Unrestricted, an exponential function may bankrupt a givenuser.

While operations in the EVM have a gas cost, gas has a “gas price”measured in ether. Transactions specify a given gas price in ether foreach unit of gas. The fixing of price by transaction enables the marketto decide the relationship between the price of ether and the cost ofcomputing operations (as measured in gas). The total fee paid by atransaction is the gas used multiplied by gas price.

If a given transaction offers very little in terms of a gas price, thattransaction will have low priority on the network. In some cases, thenetwork miners may place a threshold on the gas price each is willing toexecute/process for. If a given transaction is below that threshold forall miners, the process will never execute. Where a transaction does notinclude enough ether attached (e.g., because the transaction results inso much computational work that the gas costs exceed the attached ether)the used gas is still provided to the miners. When the gas runs out, theminer will stop processing the transaction, revert changes made, andappend to the blockchain with a “failed transaction.” Failedtransactions may occur because the miners do not directly evaluate smartcontracts for efficiency. Miners will merely execute code with anappropriate gas price attached. Whether the code executes to completionor stalls out due to excessive computational complexity is of no matterto the miner.

Where a high gas price is attached to a transaction, the transactionwill be given priority. Miners will process transactions in order ofeconomic value. Priority on the Ethereum blockchain works similarly aswith the Bitcoin blockchain. Where a user attaches more ether to a giventransaction than necessary, the excess amount is refunded back to thatuser after the transaction is executed/processed. Miners only charge forthe work that is performed. A useful analogy regarding gas costs andprice is that the gas price is similar to an hourly wage for the miner,whereas the gas cost is like a timesheet of work performed.

A type of smart contract that exists on the Ethereum blockchain areERC-20 tokens (Ethereum Request for Comment-20). ERC-20 is a technicalspecification for fungible utility tokens. ERC-20 defines a common listof rules for Ethereum tokens to follow within the larger Ethereumecosystem, allowing developers to accurately predict interaction betweentokens. These rules include how the tokens are transferred betweenaddresses and how data within each token is accessed. ERC-20 provides aframework for a means to build a token on top of a base cryptocurrency.In some embodiments herein, enhancements are built on top of the ERC-20framework, though use of the ERC-20 technical specification is notinherently necessary and is applicable to circumstances where Ethereumis used as the base cryptocurrency.

Another type of smart contract that exists on the Ethereum blockchainare ERC-721 tokens (Ethereum Request for Comment-721). ERC-721 is atechnical specification for NFTs. The ERC-721 introduces a standard forNFT. An ERC-721 token is unique and can have different exclusivity toanother token from the same smart contract, maybe due to age, rarity orvisuals.

NFTs have a uint 256 variable called tokenId. Thus, for any ERC-721contract, the pair contract address, uint 256 tokenId must be globallyunique. That said, a given dApp can have a “converter” that uses thetokenId as input and outputs an image.

Disclosure on token protocols has focused on Ethereum. As applicable inthis disclosure, this are base cryptocurrencies. Other basecryptocurrencies exist now and in the future. This disclosure is notlimited to application on specifically the Bitcoin or Ethereumblockchains.

CryptoKitties is an early example of an NFT platform. Users would engagein breeding and trading of cryptographic tokens that were visuallyrepresented by cartoon cats. Each cat had a family tree that was trackedby a blockchain and went back to the originator cats that digitallysired the subsequent cats. The visual representation of each cat had anappearance dictated by a number of preset options and was at leastpartly controlled by the visual appearance of the parent cat tokens.

Users would mate and auction cats as a game mechanic. When two catsmated, a third cat would be generated by the CryptoKitties dApp. Thethird cat was visually represented by some amalgamation of the featuresof the parents with the potential of a mutation (to potentially gain aparticularly rare feature neither of the parents exhibited). Ultimately,generation of a cryptokitty is based on the user input of existingkitties, and kitties are the only acceptable datatype. That is to say,no other types of NFT are applicable. One cannot mate a cryptokitty withan emoji ID.

CryptoKitties had a number of viral features that were indicative ofexclusivity. These features included particularly rare combinations ofvisual features and a lineage that was relatively close to an originatorcat. In both cases, there was no algorithmic benefit for either of theseexclusivity features.

While CryptoKitties does not implement any algorithmic connection toexclusivity features, some embodiments of the present invention do. Itis frequently the case that exclusivity features of NFTs are connectedto originator or early generation tokens. Additionally, tokens havingrare visual features are considered exclusive. What generation a givenNFT is, is identifiable using either metadata on the token itselfcombined with thresholds or heuristics regarding generationaldefinitions or is identifiable by tracing back the token's generationthrough the respective blockchain of that token. Rarity of visualfeatures is identified via a survey of existing tokens and the existingvisual features thereof. Thus, in embodiments of the instant inventionan evaluation is performed on each relevant token used as input thatidentifies the exclusivity features of that token, then those featuresare captured for use in generation of a new unique procedurallygenerated digital object (e.g., an NFT).

Emoji Sequence Based ID

FIG. 3 illustrates a block diagram of a system 300 for using emojisequence IDs for identifying wallet addresses of blockchain wallets.System 300 includes a blockchain network 302, user device 320, userdevice 330, and server 310.

As shown in FIG. 3 , blockchain network 302 includes a plurality ofnodes 304A-E (e.g., servers) that each maintain respective copies of ablockchain. In actual practice, blockchain network 302 may includehundreds or thousands of nodes. In some embodiments, blockchain network302 may be a distributed peer-to-peer network as is known by thoseskilled in the art. In some embodiments, blockchain network 302 of nodes304A-E implement known consensus algorithms to validate transactionssubmitted to blockchain network 302. A verified transaction may includetransferred cryptocurrency, contracts, records, or other information tobe recorded to the blockchain. In some embodiments, multipletransactions are combined together into a block of data that is verifiedacross blockchain network 302. Once verified, this block of data can beadded to an existing blockchain maintained by each of nodes 304A-E.

In some embodiments, a user can initiate transactions to be submitted toblockchain network 302 using user device 330. For example, the user maysubmit a transaction using application 331 configured to interact withblockchain network 302. For example, application 331 may generate andtransmit cryptocurrency transactions to node 304A for validation andverification. Application 331 may include software downloaded from adigital distribution platform (e.g., App Store on Apple devices orMicrosoft Store on Windows devices) or a content server. In someembodiments, application 331 provides a graphical user interface (GUI)that enables the user to generate transactions between his or herblockchain wallet and a blockchain wallet of a target recipient ofcryptocurrency funds. Conventionally, the target recipient's blockchainwallet is identified by a wallet address in a human-legible textualrepresentation. For example, the wallet address may be a string ofnumbers and/or characters such as in a hex format, a Base64 format, or aBase58 format. As described above, requiring the user to enter longstrings of numbers and/or characters into application 331 to identifythe wallet address of the target recipient is inefficient and prone toerror.

In some embodiments, to enable the user to use an emoji sequence ID touniquely identify a target wallet address for a blockchain wallet incryptocurrency transactions, application 331 can implement an emoji list332, an emoji encoder 334, and an emoji decoder 336.

In some embodiments, emoji list 332 can be stored in memory ofapplication 331 and include a predetermined list of emojis that are usedto enable use of emoji sequence IDs to identify wallet addresses ofblockchain wallets. In some embodiments, the predetermined list includesa subset of emojis selected from the emojis in the Unicode Standard. Forexample, a give emoji list 332 includes 1626 emojis selected from theUnicode Standard. In some embodiments, 1626 emojis are selected becausethree emojis selected from 1626 emojis can uniquely map to a four-bytevalue. For example, an emoji ID of three emojis selected from 1626emojis may include 1626{circumflex over ( )}3 unique emoji IDs, which isless than 0.1% more unique values than the total possible number ofunique values (i.e., 2{circumflex over( )}32) that can be represented bythe four-byte (i.e., 32-bit) value. As will be understood by thoseskilled in the art, other numbers of emojis may be selected to be partof emoji list 332 to represent different number of bits. For example, anemoji list 332 having 46 emojis can represent an 11-bit value using twoemojis (i.e., two emojis result in 46*46=2116 unique emoji IDs, whichprovides slightly more unique values than the possible values, 2048, ofan 11-bit value).

In some embodiments, emojis in emoji list 332 may be selected to bevisually dissimilar to reduce the likelihood that the user enters anincorrect emoji when entering the emoji sequence ID identifying thewallet address of the blockchain wallet. For example, the emojis may beselected such that no two emojis depict the slight variations of thesame object. For example, a single emoji for a cat may be selected andincluded in emoji list 332 and not the multiple emojis depicting catswith different expression (e.g., grinning cat, cat with tears of joy,and pouting cat, etc.).

In some embodiments, to permit conversion between emoji IDs and integervalues, emoji list 332 includes a plurality of emojis associated with aplurality of corresponding values. In some embodiments, emoji list 332can be stored as an array, in which each emoji in the array has acorresponding index based on its position in the array. Therefore, eachvalue associated with an emoji may be an index assigned to the emoji. Inother embodiments, emoji list 332 may include a table that stores aplurality of emojis and that stores a plurality of values correspondingto the plurality of emojis. In these embodiments, emojis in emoji list332 that are pictorially similar may be associated with the same value.In some embodiments, a set of emojis that is pictorially similar caninclude a plurality of emojis that depict types of the same object. Forexample, emoji list 332 may include multiple flag emojis that are eachassigned an associated value of, for example, 9.

In some embodiments, application 331 can include an emoji mapping listthat maps a larger number of emojis to the emojis in emoji list 332. Forexample, the emoji mapping list may include all available emojis in theUnicode Standard (i.e., 3,341 emojis as of January 2022). In someembodiments, by selecting mapping emojis to emojis in emoji list 332,two or more emojis that are pictorially similar may be mapped to thesame emoji. For example, two or more emojis that show a clock depictingdifferent types may be mapped to the same emoji of a clock. The use ofan emoji mapping list may normalize the possible emojis to a list ofemojis that are selected to be visually distinct to reduce error duringuser entry as well as to enhance the ease of visually verifying enteredemoji sequence IDs.

In some embodiments, emoji encoder 334 can be configured to generate anemoji sequence ID that uniquely identifies a wallet address, whichincludes a predetermined number of bits (e.g., a 128-bit address or a256-bit address). In other words, emoji encoder 334 can encode thewallet address into a sequence of emojis such that every wallet addressis uniquely represented by exactly one sequence of emojis. Further, avalid emoji sequence ID represents exactly one wallet address. Theencoding and decoding functions performed by emoji encoder 334 and emojidecoder 336, respectively, are symmetric functions. This means thatencoding a wallet address, a, to its emoji sequence ID, s, and thenapplying the decoding function to emoji sequence ID, s, will alwaysresult in the originally encoded wallet address, a.

In some embodiments, to generate the emoji sequence ID, emoji encoder334 can map a predetermined number of bits of the wallet address to apredetermined number of emojis selected from emoji list 332. In someembodiments, the predetermined number of bits of the wallet address canbe divided into a plurality of non-overlapping groups of sequentialbits. For example, the wallet address may be divided into 4-byte chunks.Then, emoji encoder 334 can convert each group of sequential bits intoan emoji ID including a predetermined number of emojis based on emojilist 332. Finally, emoji encoder 334 can generate the emoji sequence IDidentifying the wallet address by concatenating each emoji ID for eachgroup of sequential bits into an emoji sequence.

In some embodiments, emoji encoder 334 can implement a mapping algorithmto convert the wallet address into the emoji sequence ID. For example,the mapping algorithm may include a BIP39 algorithm, an Electrum schemealgorithm, or a simple mapping from emoji index to a 10-bit value foremoji list 332 having at least 1024 emojis. In some embodiments, emojiencoder 334 can implement a mapping algorithm that uses indices ofemojis in emoji list 332 to convert a numeric value to a predeterminednumber of emojis.

In some embodiments, to generate the emoji sequence ID, emoji encoder334 may calculate a checksum value for the emoji sequence. For example,emoji encoder 334 may apply a checksum algorithm such as the Dammalgorithm to calculate the checksum value. Then, emoji encoder 334 mayconvert the checksum value into an emoji representation including apredetermined number of emojis. Finally, emoji encoder 334 may outputthe emoji sequence ID identifying the wallet address by appending theemoji representation for the checksum to the emoji sequence previouslycalculated.

In some embodiments, emoji decoder 336 can be configured to generate awallet address, which includes a predetermined number of bits (e.g., a128-bit address or a 256-bit address), that is uniquely identified by anemoji sequence ID. In other words, emoji decoder 336 can decode theemoji sequence ID identifying the wallet address into a sequence oftextual representations that uniquely corresponds to the wallet address.In some embodiments, the textual representation can correspond to analphanumeric format for the wallet address that is required byblockchain network 302 to process cryptocurrency transactions. Forexample, the sequence of textual representations may be a hexadecimalstring, a Base64 string, or a Base58 string.

In some embodiments, to generate the sequence of textual representationsthat identifies the wallet address, emoji decoder 336 can map thesequence of emojis in the emoji sequence ID to a numerical valueidentifying the wallet address based on emoji list 332. In someembodiments, emoji decoder 336 can determine the numerical value usingemoji list 332 to identify a plurality of values corresponding to theplurality of emojis in the emoji sequence ID. For example, for an emojiin the emoji sequence ID, emoji decoder 336 may use an index of theemoji identified in emoji list 332 as a value associated with the emojito be used in generating the numerical value. In some embodiments, emojidecoder 336 can convert a generated numerical value into the sequence oftextual representations that uniquely identifies the wallet address.

In some embodiments, emoji decoder 336 can apply a checksum algorithm onthe emoji sequence ID to determine whether the emoji sequence ID isvalid. For example, emoji decoder 336 may apply the checksum algorithmto check whether the last emoji in the emoji sequence ID matches aresult of the checksum algorithm applied to the emoji sequence IDexcluding the last emoji. As described above with respect to emojiencoder 334, the last emoji may be generated to represent a checksumvalue of the emoji sequence ID. In some embodiments, if the checksumfails, emoji decoder 336 can halt processing because emoji sequence IDis invalid. In some embodiments, emoji decoder 336 can generate anotification indicating that the sequence ID is invalid.

In some embodiments, one or more emoji checksum can be extracted fromthe emoji sequence ID to generate a resultant emoji sequence. In someembodiments, the resultant emoji sequence can be divided into aplurality of non-overlapping groups of sequential emojis. For example,for an emoji list 332 having 1626 emojis, the result emoji sequence maybe divided into groups of 3 emojis, with each group representing a4-byte value. Then, emoji decoder 336 can convert each group ofsequential emojis into a textual representation including apredetermined number of bits based on emoji list 332. Finally, emojidecoder 336 can generate the sequence of textual representationsidentifying the wallet address by concatenating each textualrepresentation for each group of sequential emojis.

In some embodiments, functionality of application 331 may be performedelsewhere in system 300 such as on one or more of nodes 304A-E inblockchain network 302. In these embodiments, blockchain network 302 canbe configured to be capable of processing transactions in which walletaddresses are identified using emoji sequence IDs. In some embodiment,an emoji sequence ID is a sequence of a plurality of emojis.

In some embodiments, functionality of application 331 may be performedelsewhere in system 300 such as on server 310. For example, server 310includes emoji list 312, emoji encoder 314, and emoji decoder 316, whichprovides similar functionality as emoji list 332, emoji encoder 334, andemoji decoder 336, respectively. In some embodiments, server 310 may bea web server that enables users to operate a client 322 on user device320 to access the functions of server 310. For example, client 322 maybe a browser that enables the user to connect to a web portal orinterface provided by server 310. Therefore, a user using user device320 may initiate transactions to be verified by and added to blockchainnetwork 302 via server 310.

Unique Digital Object Generation

FIG. 4 is a flowchart illustrating platform generation of a uniqueprocedurally generated object via user specific parameters. In step 402,the digital object generator establishes a set of input types andparameters handled. Examples of the types of input include handled byvarious embodiments include any combination of cryptographic protocols,image data, or multimedia data.

Input handling refers to the types of input a given platform understandsor recognizes. When designing input handling, the platform firstrecognizes what sort of input is given to it, and then when to do withthe parameters of the input.

With reference to recognition of cryptographic protocols, a given inputmay be a cryptographic wallet, and the tokens associated therewith. Insome cases, a given cryptographic wallet is associated with tokens frommultiple cryptographic object types that each have their own smartcontract, or blockchain upon which those objects are tracked. A commonblockchain used for NFTs at the time of this application is the Ethereumblockchain. However, it is contemplated, that NFTs may operate ondifferent blockchains in the future. A given token within a wallettypically has a call or an identifying feature that indicates which dAppthe token is associated with.

With reference to image data, a given input may be a .jpeg or some otherdigital image format. In such examples, the file extension identifieswhat the input is, and the parameters thereof are identified viacomputer vision techniques. Similar input identification is applied tomultimedia input.

Other data types may include user accounts, or game save files. Gamesave files often include data regarding characters the user has played,a total play time, items held by the user's character, choices thecharacter has made, or other game related aspects. An example of a useraccount is a social media account, where data included relates to numberof posts made, posts that had the highest amount of interaction (in anycombination of negative/positive), number of followers, and other socialmedia related aspects. Some embodiments of the present invention makeuse of these data types and parameters.

In step 404, the digital object generator establishes a model thatprocedurally converts the received user parameters and input into adigital object via a one-way function. The model used varies based onthe style of input used. The process is ultimately transformative on theinput and while, in some embodiments, the output may be indicative orreminiscent of the original input, computationally deriving the exactinputs from the output is not seen as a viable problem using modemcomputing techniques.

The simplest embodiment is a hash function the converts data embodied ina given format (e.g., binary, alphanumeric, ASCII, array of values,etc.) into a hash value. More complex embodiments make use of multiplemodels or schemes to convert multiple data types into a common datatype/data structures and subsequently apply a model that generates anamalgamated output. For example, with respect to ERC-721 tokens, a modelidentifies exclusivity features of that ERC-721 token. The exclusivityfeatures are identified via examination of the relevant smart contractusing an associated dApp plugin/API with the ERC-721 token. Theexclusivity features for that given token may differ based on therelevant smart contract the token is associated with, though someexclusivity features are relatively universal.

Examples of identifying exclusivity features include ID number (numericcount) or identifying the generation of the token as compared to thetotal number of generations of token. Generations in this context referto how close the token is to originally minted tokens of the same smartcontract. Generations are cycles or series of minting of tokens in agiven smart contract. Typically, earlier generation tokens areconsidered more exclusive. Further traceable features include a numberof times a given token has changed hands, a value of each exchange ofthat token in cryptocurrency or fiat, and rarity of visual featuresincluded with the token.

Rarity of visual features on a token varies on a smart contract by smartcontract basis. In some cases, there is an algorithmic rarity offeatures dictated in the smart contract. In such cases, the rarity ofvisual features is a static lookup. In some cases, the rarity of a givenvisual feature or combination of visual features is determined via asurvey of existing NFTs associated with a given contract. With respectto a cryptokitty, a rare color is “cloud white” coloring. In each case,a model evaluates these features and weights each and generating arespective weight across a given set of input for the user.

A type of model that has advantages over reviewing potentiallydissimilar data types is a few-shot model. Initially the few-shot modelis trained using various data that users associate with themselves.Examples include are social networking profiles, art, videos, audiorecordings, virtual environments, ERC-721 tokens and associatedprotocols and dApps, and publicly posted Internet discourse. Trainingdata typically refers to an enormous number of examples, such ashundreds of thousands or millions of examples. After being trained, theuser specific parameters act as a few-shot. Each of the user input itemsneed not be of a similar type, and the model will attempt to fit thereceived input into categories the model has been trained with. Each ofthe input parameters potentially has very little in common with respectto data types.

The few-shot model is designed to identify and extract particular mediafeatures in the few-shot (the user's specific parameters). A follow upmodel then identifies which features to use and what to do with thosefeatures. For example, a graphic feature of one element of user specificinput may include a hat, while yet another graphic feature of adifferent element of user specific input may include a head. The modelis trained that hats go on heads and that the graphic feature of a hatfrom one element may be transposed onto the graphic feature of the otherelement including a head.

Based on configurations of the model the resulting digital object mayvary. One example of a resulting digital object is an ERC-721 token thatincludes a visual component. In some embodiments, the visual componenttakes exclusivity elements from the user's input and integrates thosecomponents into a single visual representation. A given example is asingle image of a mashup of initial input. Another example is a 3Dvirtual environment that includes a set of trophies resembling theinitial input. A third example is a written poem that rhymes variouselements of the initial input. The digital object need not be an NFT.Rather, a digital object refers to a set of data that describes adiscrete output in a digital format.

In step 406, a given user submits their user specific parameters to thedigital object generator. In step 408, the model executes utilizing theuser specific parameters and generals a user specific, unique, digitalobject. In some embodiments, the generation of the object is embodied bythe minting of an ERC-721 token. In step 410, where there are additionalusers, the process repeats from step 406.

FIG. 5 is an illustration of a new digital object generated from a setof user input. The illustration includes three visual representations ofexisting NFTs, Specifically, a cryptokitty input 502, a Bored Ape input504, and a Yat input 506 as provided as examples of initial user input.Each of the NFT's is further connection to a cryptographic record on adApp, and the visual representation is interpreted by the respectivedApp. A new digital object 508 is depicted that incorporates elements ofthe visual representation of each. In this illustrative example of thenew digital object 508, the cryptokitty graphic of the cryptokitty input502 appears with a hat and cigar graphic from the bored ape input 504,and the emoji of the Yat input 506 positioned on the belly of thecryptokitty graphic.

FSL embodiments applied to this particular set of input identifies eachgraphic feature of the user input. The cryptokitty input 502 is acartoon cat, the cat has a head, a mouth, and a clearly delineatedstomach area (among other body parts). The bored ape input 504 is acartoon of an ape wearing a hat and smoking a cigar. The Yat input 506is an emoji graphic.

Given the extracted features a model trained to select and combine thefeatures that fit with one another matches a hat to a head a mouth to acigar and an emoji graphic to an open space to position a graphic (e.g.,well-defined stomach area).

The resulting digital object is the result of a one-way function. In thedepicted example, one cannot, for instance, identify all of the detailsof the bored ape input 504, but may be able to identify that theoriginal input included a bored ape based on the art style.

FIG. 6 is a flowchart illustrating model operation step of a uniqueprocedurally generated object via user specific parameters. In step 602,a set of user specific parameters are received by a feature extractionmodel. An embodiment of the feature extraction model is a few-shotmodel. The term “feature” refers to graphic features, audio features,cryptographic protocol features, video features, spatial virtualfeatures, textual features, and/or social media features.

In step 604, extracted features are indicated to a feature evaluationmodel. The feature evaluation model identifies which of the extractedfeatures to use in generation of the digital object. The model choosesfeatures based on distinctiveness (e.g., how different they are fromother available features), interoperability (e.g., how functionally agiven feature can mix with another feature), and/or exclusivity (e.g.,the rarity of a given feature).

In step 606, the chosen features are amalgamated by an artistic model.In some embodiments the artistic model and the feature evaluation modelgenerate a result together. The artistic model is trained regarding whatfeatures go together. In some cases, “going together” is defined in themodel semantically. That is to say, for example, that hats go on heads.That is a semantic connection between objects. However, some embodimentsof the artistic model define “going together” as graphic matches betweencontours, colors, shadings, or other visual elements. For example, onecurved element is a near match to another curved element, so one ofthose elements may overlay on another using curve matching. Similar tographic matching, auditory matching may combine audio clips at a pointwhere a similar note series occurs.

In step 608, once the elements are extracted, evaluated and combined,the digital object generator prints/mints the new digital object.

Time/Location-Based Modification of Digital Objects

User parameters have thus far been defined as something that solely agiven user provides. However, in some embodiments, parameters used bythe digital object generator are circumstantial to the minting request.Examples include a current generation/minting series of digital objectsbeing generated, the serial numbers of the digital objects being minted,the timestamp the digital object is being minted at, or current eventsaround the time of minting (e.g., The Superbowl, a concert, aconvention, etc.). Location is identified as a device location of a userdevice requesting generation/minting of the digital object as associatedwith addresses, buildings, or events. Device location is determined viaGPS data and/or wireless network triangulation. The location data isassociated with the physical area by overlaying the location data on amapping program that includes metadata of buildings and/or events at thephysical area of the location data.

In some embodiments, the time/location-based modification is used as asalt or a randomization element to a given input set. In someembodiments, the time/location-based modification element isidentifiable from the resulting digital object is (e.g., while thefunction is one-way, at least the time-based input feature is fullyidentifiable). Time/location-based input features enable an additionalmeans of variation, distinction, and social features.

FIG. 7 is a flowchart illustrating implementation of time-based input todigital object generation. In step 702, the digital object generatorreceives a request to mint a new digital object. In step 704, userspecific parameters are received by the digital object generator. Instep 706, one or more of a time element and/or a location element iscaptured based on any of the present time, the minting status of digitalobjects, and/or where the request of step 702 was made from.

In step 708, the models responsible for digital object generationevaluate the user specific parameters and the time/location elementgiving high weight to the time/location element. In step 710, thedigital object generator mints a digital object including thetime/location element.

Blockchain Tracing of Digital Objects

Like Emoji sequences as described above, embodiments of the digitalobjects are encodable to a distributed consensus network such as ablockchain. An example blockchain is the Ethereum blockchain, viaERC-721 tokens. Whereas emoji sequences have a finite number ofpotential characters, the digital objects described herein do not. Atheoretical encoding scheme is unable to scale indefinitely to match thenumber of characters/elements/formats that embody a given digitalobject.

A means to limit the number of variables to represent in a given digitalobject is to limit the number of digital objects in any given series orgeneration (e.g., 1000 digital objects). Where a series or generation isencoded to a portion of a cryptographic token, encoding may be refreshedand reused in subsequent series. For example, a first data unit (e.g., abyte) is used to identify the generation of the digital object whereassubsequent data units are used to encode the visual features of thedigital object. The same encoding is subsequently used in a differentgeneration to refer to a different visual feature.

Generational divisions are also effectuated through event-based mintingof digital objects. FIG. 8 is a diagram illustrating a connectionbetween digital objects and a distributed consensus network supported bya blockchain data structure. A digital object creation platform 800interfaces with a blockchain 802 via a dApp/smart contract 804A/B. Thesmart contract 804B is executed by miners 806.

When a user 808 requests minting of a new digital object via the dApp804A, the dApp makes calls to other dApps connected with the user device810 in order to identify other NFTs that the user has possession of viathe other dApps. Embodiments of triggers to call other dApps includeidentifying other dApp software on the device 810 making the request tomint the new digital object, checking a list of popular dApps, and/orenabling the user to identify/flag (e.g., via GUI) which dApps they wishto flag for inspection for purposes of generating the new digitalobject.

In some embodiments, the dApp 804A ensures possession of the other NFTsused as input in the same user wallet 812 as the user wallet 812associated with the initial request to generate the digital object. Inthis way, users are forced to actually own the NFTs that they aresupplying as input for the generation of the digital object.

The check identifies the public key that is associated with both therequestor 808, and all of the user specific parameter/input. By natureof public keys being public information, no secret information need beshared with the dApp 804A.

Once minted, the dApp 804A delivers the new digital object as acryptographic token/NFT to the cryptographic wallet 812 associated withthe requesting user 808 via the smart contract 804A.

FIG. 9 is a flowchart illustrating event driven generation of digitalobjects. Event driven digital objects aid in limiting the number ofdigital objects in a series or generation such that only digital objectsthat were generated during or at a given event exist, thereby limitingthe total number. Limiting the total number serves both exclusivity ofthe digital objects and simplicity of coding the objects. Fewer digitalobjects mean fewer total variations across the entire set of digitalobjects and thus less data is required to represent the visual assetsassociated therewith.

In step 902, a set of users attend an event. Verification of attendanceoccurs in one or more of user device location data, ticket data, guestlist data, user activity on a predetermined web host, and/or ownershipof an NFT connected to event admittance (e.g., convention, gala,sporting event, etc. . . . ). In step 904, during the event an attendinguser requests to mint a new digital object. In step 906, the digitalobject generation platform generates a digital object based on theevent. In step 908, the non-cryptographic, user decipherablerepresentation of the digital object is encoded to the smart contractusing assets that are linked to the event.

Digital Object Social Networking Communities

Embodiments of social networks connect users based on possession ofdigital objects. A social network is a computing construct that connectsusers in a graph data structure including social features.

FIG. 10 illustrates a number of emoji sequences that are connected viasocial networking features based on the features included in each emojisequence. Emoji sequences such as those under marketed as Yats includeorder specific sequences of emojis that are selected by their respectiveusers. Users select particular sequences of emoji for any number ofreasons, though some do so out of an affinity to a given emoji or seriesof emojis. Some users further use the sequence of emojis to tell anarrative.

Emoji sequences 1002A-D are arranged to align commonality between eachsequence vertically. A sample social network for a user havingpossession of the emoji sequence 1002C is portrayed. Specially, the userin possession of sequence 1002C is connected 1004 to users in possessionof 1002A and 1002B by virtue of sharing a sunglasses smiley emoji ineach respective emoji sequence. In some embodiments (not pictured),social connections are limited to those emoji sequences that positionmatching emojis in matching sequence locations.

Emoji sequence 1002C and 1002D are further socially connected 1006 basedon similar inclusion of the telescope emoji. In some embodiments adegrees of connection analysis (e.g., “6 degrees”) is performed tofurther connect users associated with emoji sequences. For example, theuser associated with emoji sequence 1002A is connected via one degreeaway from emoji sequence 1002D, via the social connection to 1002C. Insome embodiments social features between connected users enable sharednewsfeeds, message delivery, and/or interactive games.

While the example depicted in the figure pertains to social connectionsvia emoji sequences, similar social connections are established betweendigital object owners. For example, digital object owners that haverespective digital objects that similarly made use of a give type ofERC-721 token are linked in the same way users with matching emoji useare linked (e.g., users that have a Yat, or users that have acryptokitty, etc.).

Interrelation of Digital Objects

In some embodiments digital objects interrelate and have functionalitywith one another. Described below are a number of embodiments ofinterrelation:

A) a first digital object is enabled to generate further derivativedigital objects. The derivative digital objects may be distributed atwill, but if the first digital object changes possession, all derivativedigital objects deactivate. For purposes of this disclosure and otherexamples, the term “Deactivate” refers to any of: losing allfunctionality, losing any user decipherable representation, and/or beingdeleted. Various embodiments implement deactivation either throughinternal programing of the digital object, or as conditions within asmart contract the digital object is associated with.

B) a first digital object is an NFT and is associated with acryptographic wallet that further has the input used to generate thefirst digital object. Where any of the original input are transferredaway from the cryptographic wallet, the first digital object isdeactivated.

C) a first digital object is an NFT and is associated with acryptographic wallet that further has the input used to generate thefirst digital object. Where the first digital object is transferred awayfrom the cryptographic wallet, the first digital object is deactivated.

Computing Platform

FIG. 11 is a block diagram illustrating an example computer system 1100,in accordance with one or more embodiments. In some embodiments,components of the example computer system 1100 are used to implement thesoftware platforms described herein. At least some operations describedherein can be implemented on the computer system 1100.

The computer system 1100 can include one or more central processingunits (“processors”) 1102, main memory 1106, non-volatile memory 1110,network adapters 1112 (e.g., network interface), video displays 1118,input/output devices 1120, control devices 1122 (e.g., keyboard andpointing devices), drive units 1124 including a storage medium 1126, anda signal generation device 1120 that are communicatively connected to abus 1116. The bus 1116 is illustrated as an abstraction that representsone or more physical buses and/or point-to-point connections that areconnected by appropriate bridges, adapters, or controllers. The bus1116, therefore, can include a system bus, a Peripheral ComponentInterconnect (PCI) bus or PCI-Express bus, a HyperTransport or industrystandard architecture (ISA) bus, a small computer system interface(SCSI) bus, a universal serial bus (USB), IIC (I2C) bus, or an Instituteof Electrical and Electronics Engineers (IEEE) standard 1394 bus (alsoreferred to as “Firewire”).

The computer system 1100 can share a similar computer processorarchitecture as that of a desktop computer, tablet computer, personaldigital assistant (PDA), mobile phone, game console, music player,wearable electronic device (e.g., a watch or fitness tracker),network-connected (“smart”) device (e.g., a television or home assistantdevice), virtual/augmented reality systems (e.g., a head-mounteddisplay), or another electronic device capable of executing a set ofinstructions (sequential or otherwise) that specify action(s) to betaken by the computer system 1100.

While the main memory 1106, non-volatile memory 1110, and storage medium1126 (also called a “machine-readable medium”) are shown to be a singlemedium, the term “machine-readable medium” and “storage medium” shouldbe taken to include a single medium or multiple media (e.g., acentralized/distributed database and/or associated caches and servers)that store one or more sets of instructions 1128. The term“machine-readable medium” and “storage medium” shall also be taken toinclude any medium that is capable of storing, encoding, or carrying aset of instructions for execution by the computer system 1100. In someembodiments, the non-volatile memory 1110 or the storage medium 1126 isa non-transitory, computer-readable storage medium storing computerinstructions, which can be executed by the one or more centralprocessing units (“processors”) 1102 to perform functions of theembodiments disclosed herein.

In general, the routines executed to implement the embodiments of thedisclosure can be implemented as part of an operating system or aspecific application, component, program, object, module, or sequence ofinstructions (collectively referred to as “computer programs”). Thecomputer programs typically include one or more instructions (e.g.,instructions 1104, 1108, 1128) set at various times in various memoryand storage devices in a computer device. When read and executed by theone or more processors 1102, the instruction(s) cause the computersystem 1100 to perform operations to execute elements involving thevarious aspects of the disclosure. 32N Moreover, while embodiments havebeen described in the context of fully functioning computer devices,those skilled in the art will appreciate that the various embodimentsare capable of being distributed as a program product in a variety offorms. The disclosure applies regardless of the particular type ofmachine or computer-readable media used to actually effect thedistribution.

Further examples of machine-readable storage media, machine-readablemedia, or computer-readable media include recordable-type media such asvolatile and non-volatile memory devices 1110, floppy and otherremovable disks, hard disk drives, optical discs (e.g., Compact DiscRead-Only Memory (CD-ROMS), Digital Versatile Discs (DVDs)), andtransmission-type media such as digital and analog communication links.

The network adapter 1112 enables the computer system 1100 to mediatedata in a network 1114 with an entity that is external to the computersystem 1100 through any communication protocol supported by the computersystem 1100 and the external entity. The network adapter 1112 caninclude a network adapter card, a wireless network interface card, arouter, an access point, a wireless router, a switch, a multilayerswitch, a protocol converter, a gateway, a bridge, a bridge router, ahub, a digital media receiver, and/or a repeater.

The network adapter 1112 can include a firewall that governs and/ormanages permission to access proxy data in a computer network and tracksvarying levels of trust between different machines and/or applications.The firewall can be any number of modules having any combination ofhardware and/or software components able to enforce a predetermined setof access rights between a particular set of machines and applications,machines and machines, and/or applications and applications (e.g., toregulate the flow of traffic and resource sharing between theseentities). The firewall can additionally manage and/or have access to anaccess control list that details permissions including the access andoperation rights of an object by an individual, a machine, and/or anapplication, and the circumstances under which the permission rightsstand.

The techniques introduced here can be implemented by programmablecircuitry (e.g., one or more microprocessors), software and/or firmware,special-purpose hardwired (i.e., non-programmable) circuitry, or acombination of such forms. Special-purpose circuitry can be in the formof one or more application-specific integrated circuits (ASICs),programmable logic devices (PLDs), field-programmable gate arrays(FPGAs), etc. A portion of the methods described herein can be performedusing the example ML system 1200 illustrated and described in moredetail with reference to FIG. 12 .

Machine Learning System

FIG. 12 is a block diagram illustrating an example ML system 1200, inaccordance with one or more embodiments. The ML system 1200 isimplemented using components of the example computer system 1100illustrated and described in more detail with reference to FIG. 9 .Likewise, embodiments of the ML system 1200 can include different and/oradditional components or be connected in different ways. The ML system1200 is sometimes referred to as a ML module.

The ML system 1200 includes a feature extraction module 1208 implementedusing components of the example computer system 1100 illustrated anddescribed in more detail with reference to FIG. 11 . In someembodiments, the feature extraction module 1208 extracts a featurevector 1212 from input data 1204. For example, the input data 1204 caninclude one or more images, sets of text, audio files, or video files.The feature vector 1212 includes features 1212 a, 1212 b, . . . 1212 n.The feature extraction module 1208 reduces the redundancy in the inputdata 1204, e.g., repetitive data values, to transform the input data1204 into the reduced set of features 1212, e.g., features 1212 a, 1212b, . . . 1212 n. The feature vector 1212 contains the relevantinformation from the input data 1204, such that events or data valuethresholds of interest can be identified by the ML model 1216 by usingthis reduced representation. In some example embodiments, dimensionalityreduction techniques, such as principal component analysis (PCA) orautoencoders are used by the feature extraction module 1208.

In alternate embodiments, the ML model 1216 performs deep learning (alsoknown as deep structured learning or hierarchical learning) directly onthe input data 1204 to learn data representations, as opposed to usingtask-specific algorithms. In deep learning, no explicit featureextraction is performed; the features 1212 are implicitly extracted bythe ML system 1200. For example, the ML model 1216 can use a cascade ofmultiple layers of nonlinear processing units for implicit featureextraction and transformation. Each successive layer uses the outputfrom the previous layer as input. The ML model 1216 can learn insupervised (e.g., classification) and/or unsupervised (e.g., patternanalysis) modes. The ML model 1216 can learn multiple levels ofrepresentations that correspond to different levels of abstraction,wherein the different levels form a hierarchy of concepts. In thismanner, the ML model 1216 can be configured to differentiate features ofinterest from background features.

In alternative example embodiments, the ML model 1216, e.g., in the formof a CNN generates the output 1224, without the need for featureextraction, directly from the input data 1204. The output 1224 isprovided to the computer device 1228. The computer device 1228 is aserver, computer, tablet, smartphone, smart speaker, etc., implementedusing components of the example computer system 1100 illustrated anddescribed in more detail with reference to FIG. 11 . In someembodiments, the steps performed by the ML system 1200 are stored inmemory on the computer device 1228 for execution. In other embodiments,the output 1224 is displayed on high-definition monitors.

A CNN is a type of feed-forward artificial neural network in which theconnectivity pattern between its neurons is inspired by the organizationof a visual cortex. Individual cortical neurons respond to stimuli in arestricted region of space known as the receptive field. The receptivefields of different neurons partially overlap such that they tile thevisual field. The response of an individual neuron to stimuli within itsreceptive field can be approximated mathematically by a convolutionoperation. CNNs are based on biological processes and are variations ofmultilayer perceptrons designed to use minimal amounts of preprocessing.

The ML model 1216 can be a CNN that includes both convolutional layersand max pooling layers. The architecture of the ML model 1216 can be“fully convolutional,” which means that variable sized sensor datavectors can be fed into it. For all convolutional layers, the ML model1216 can specify a kernel size, a stride of the convolution, and anamount of zero padding applied to the input of that layer. For thepooling layers, the ML model 1216 can specify the kernel size and strideof the pooling.

In some embodiments, the ML system 1200 trains the ML model 1216, basedon the training data 1220, to correlate the feature vector 1212 toexpected outputs in the training data 1220. As part of the training ofthe ML model 1216, the ML system 1200 forms a training set of featuresand training labels by identifying a positive training set of featuresthat have been determined to have a desired property in question and anegative training set of features that lack the property in question.The ML system 1200 applies ML techniques to train the ML model 1216,that when applied to the feature vector 1212, outputs indications ofwhether the feature vector 1212 has an associated desired property orproperties.

The ML system 1200 can use supervised ML to train the ML model 1216,with features from the training sets serving as the inputs. In someembodiments, different ML techniques, such as support vector machine(SVM), regression, naïve Bayes, random forests, neural networks, etc.,are used. In some example embodiments, a validation set 1232 is formedof additional features, other than those in the training data 1220,which have already been determined to have or to lack the property inquestion. The ML system 1200 applies the trained ML model 1216 to thefeatures of the validation set 1232 to quantify the accuracy of the MLmodel 1216. In some embodiments, the ML system 1200 iterativelyre-trains the ML model 1216 until the occurrence of a stoppingcondition, such as the accuracy measurement indication that the ML model1216 is sufficiently accurate, or a number of training rounds havingtaken place.

The description and drawings herein are illustrative and are not to beconstrued as limiting. Numerous specific details are described toprovide a thorough understanding of the disclosure. However, in certaininstances, well-known details are not described in order to avoidobscuring the description. Further, various modifications can be madewithout deviating from the scope of the embodiments.

Consequently, alternative language and synonyms can be used for any oneor more of the terms discussed herein, nor is any special significanceto be placed upon whether or not a term is elaborated or discussedherein. Synonyms for certain terms are provided. A recital of one ormore synonyms does not exclude the use of other synonyms. The use ofexamples anywhere in this specification including examples of any termdiscussed herein is illustrative only and is not intended to furtherlimit the scope and meaning of the disclosure or of any exemplifiedterm. Likewise, the disclosure is not limited to various embodimentsgiven in this specification.

It is to be understood that the embodiments and variations shown anddescribed herein are merely illustrative of the principles of thisinvention and that various modifications can be implemented by thoseskilled in the art.

Note that any and all of the embodiments described above can be combinedwith each other, except to the extent that it may be stated otherwiseabove or to the extent that any such embodiments might be mutuallyexclusive in function and/or structure.

Although the present invention has been described with reference tospecific exemplary embodiments, it will be recognized that the inventionis not limited to the embodiments described, but can be practiced withmodification and alteration within the spirit and scope of the appendedclaims. Accordingly, the specification and drawings are to be regardedin an illustrative sense rather than a restrictive sense.

1. (canceled)
 2. A method of employing an artificial intelligence modelto generate a set of image data comprising: training a machine learningmodel with a set of training data configured to extract visual featuresassociated with a set of images; receiving user specific parametersassociated with a first user including a prompt; extracting visualfeatures from the set of images consistent with the prompt; identifying,via the machine learning model, a set of elements from the extractedvisual features that meet a threshold model confidence for amalgamation;and generating an output image that corresponds to the user specificparameters and based on the set of elements.
 3. The method of claim 2,further comprising: minting the output image as a cryptographic token.4. The method of claim 3, further comprising: encoding the output imageto a cryptographic token ID stored in a smart contract associated withthe cryptographic token.
 5. The method of claim 2, wherein the machinelearning model is further trained to extract cryptographic elements fromthe user specific parameters including a generation of token for eachcryptographic token, and wherein said generating the output imagefurther corresponds to the cryptographic elements.
 6. The method ofclaim 2, wherein said extracting is performed by a few-shot modelarchitecture that performs feature identification via a support set thatincludes a set of graphic features indicated by the prompt.
 7. Themethod of claim 2, further comprising: training the machine learningmodel to identify contextual rarity in a cryptographic token as afunction of adherence to predetermined categories as opposed to objectuniqueness.
 8. The method of claim 7, wherein the output imageincorporates elements of the contextual rarity of the user specificparameters.
 9. The method of claim 2, wherein said generating the outputimage generates a model-unique image.
 10. A system of employing anartificial intelligence model to generate a set of image datacomprising: a processor; and a memory including instructions that whenexecuted, cause the processor to: train a machine learning model with aset of training data configured to extract visual features associatedwith a set of images; receive user specific parameters associated with afirst user including a prompt; extract visual features from the set ofimages consistent with the prompt; identify, via the machine learningmodel, a set of elements from the extracted visual features that meet athreshold model confidence for amalgamation; and generate an outputimage that corresponds to the user specific parameters and based on theset of elements.
 11. The system of claim 10, the instructions furthercomprising: minting the output image as a cryptographic token.
 12. Thesystem of claim 11, the instructions further comprising: encoding theoutput image to a cryptographic token ID stored in a smart contractassociated with the cryptographic token.
 13. The system of claim 10,wherein the machine learning model is further trained to extractcryptographic elements from the user specific parameters including ageneration of token for each cryptographic token, and wherein saidgenerating the output image further corresponds to the cryptographicelements.
 14. The system of claim 10, wherein said extracting isperformed by a few-shot model architecture that performs featureidentification via a support set that includes a set of graphic featuresindicated by the prompt.
 15. The system of claim 10, the instructionsfurther comprising: training the machine learning model to identifycontextual rarity in a cryptographic token as a function of adherence topredetermined categories as opposed to object uniqueness.
 16. The systemof claim 15, wherein the output image incorporates elements of thecontextual rarity of the user specific parameters.
 17. The system ofclaim 10, wherein the generation of the output image generates amodel-unique image.
 18. A non-transitory computer-readable medium thatcontains a plurality of instructions that employ an artificialintelligence model to generate a model-unique set of image data and whenexecuted by a processor cause the processor to: train a machine learningmodel with a set of training data configured to extract visual featuresassociated with a set of images; receive user specific parametersassociated with a first user including a prompt; extract visual featuresfrom the set of images consistent with the prompt; identify, via themachine learning model, a set of elements from the extracted visualfeatures that meet a threshold model confidence for amalgamation; andgenerate an output image that corresponds to the user specificparameters and based on the set of elements, wherein the output image isa model-unique image.
 19. The non-transitory computer-readable medium ofclaim 18, the instructions further comprising: minting the output imageas a cryptographic token.
 20. The non-transitory computer-readablemedium of claim 19, the instructions further comprising: encoding theoutput image to a cryptographic token ID stored in a smart contractassociated with the cryptographic token.
 21. The non-transitorycomputer-readable medium of claim 18, wherein the machine learning modelis further trained to extract cryptographic elements from the userspecific parameters including a generation of token for eachcryptographic token, and wherein said generating the output imagefurther corresponds to the cryptographic elements.
 22. Thenon-transitory computer-readable medium of claim 18, wherein saidextracting is performed by a few-shot model architecture that performsfeature identification via a support set that includes a set of graphicfeatures indicated by the prompt.